Also -- this PR was written on top of #8148. I can rebase this once the other PR lands.

I also ran this on one of our internal codebases and confirmed there were no new errors, with the exception of one or two (legitimate) "unnecessary cast" errors.

I'm glad to see this landing.

My comment on your second type-narrowing sample, where checking the state limits the operations available, I would argue that the Worker type shouldn't be written to narrow its attributes based on the state. The query() method almost certainly doesn't cease to exist when worker.state == 'ready'. I feel like that's abusing the type system; type narrowing is there to clarify the type of worker as of its last assignment, and not to try to keep up with how the type might change itself as time goes by.

TypeScript doesn't support that use case, and I don't feel like you should have to, either.

@fluggo -- ah, sorry. To clarify, the last example isn't attempting to narrow the type of worker in any way, just worker.state.

Basically, the core problem is that just blindly applying the way mypy normally narrows variables ends up causing too many issues. For example, here's how mypy currently narrows the following program:

class A: pass
class B: pass

def test(x: object) -> None:
    assert isinstance(x, A)
    reveal_type(x)  # Revealed type is 'A'

    assert isinstance(x, B)
    reveal_type(x)  # No output: stmt is unreachable; mypy thinks the assert is always false

In this case, the behavior is mostly reasonable. While 'x' could theoretically be a type that multiply inherits from both A and B, it usually isn't, so concluding that the final assert will always be False and the last line to be unreachable is a reasonable heuristic. (And when/if mypy starts understanding the notion of intersection types, it could maybe infer x is an intersection of A and B, but whatever, that's a separate issue.)

So, since Literal types are supposed to be treated more or less as regular subtypes of the underlying type, it might initially make sense to do the same thing there:

def test(x: int) -> None:
    assert x == 10
    reveal_type(x)  # Suppose we narrowed so the revealed type is Literal[10]

    assert x == 20  # Then, mypy would conclude x can't be both 10 and 20
    reveal_type(x)  # ...and since the assert is always false, this is unreachable

Attempting to narrow is reasonable in this specific case, since the last assert genuinely will always be false, since there's no way for the value of 'x' to abruptly change in after the first assert.

But the expression we're narrowing can abruptly change if it's, say, some object attribute instead of just a variable. The 'worker' example I had was just trying to show a realistic example of where this happens: a method changes some internal field, and we check the new value is what we expected in some test case.

This "what if a method changes an attribute and causes our narrowing to be bogus" problem also appears when narrowing regular types with isinstance(...) as well. It's just that it's (probably) pretty uncommon for real-world objects to have some field of type Union[A, B] and keep dynamically switching from one to another.

That is, while our current heuristics for type-level narrowing are sometimes mildly problematic, attempting apply them for value-level narrowing ends up being actually problematic.

So we need to adjust how we do value-level narrowing in some way (disable them for asserts? change the behavior of asserts so they override instead of narrowing? do the narrowing only if the attribute is Final? infer a pseudo instance/Literal hybrid? give up and tell users to use enums if they want this sort of narrowing?), and I ended up going with the "require the LHS or RHS to explicitly use Literals" approach.

And in practice, this ends up meaning that the thing you're narrowing needs to be a Union of Literals. (This conveniently happens to be just what you need if you want tagged unions w/o having to use enum everywhere.)

That said, I'm not really sure whether this is good enough either. Sure, it'll ensure that the 'worker' example doesn't end up with any unreachable statements if worker.state was originally defined to be type str. But if it were defined to be type Literal["ready", "running", "paused", "done"] or something, we'd end up right back where we started with the last assert being inferred to be always False.

¯\_(ツ)_/¯

I see what you're saying now. I ran the same sample through TypeScript, and I was surprised to find that the same example fails there:

class Worker {
  state: 'ready' | 'running';

  start() {
    this.state = 'running';
  }

  query() {
  }
}

function someTestCase(): void {
  const worker = new Worker();

  if(worker.state !== 'ready')
    throw new Error('');

  worker.start();

  if(worker.state !== 'running')   // Error: This condition will always return 'true' since the types '"ready"' and '"running"' have no overlap. ts(2367)
    throw new Error('');

  worker.query();
}

It seems the solution in TypeScript is exactly as you proposed: don't define a "status"-like field as type Literal. TypeScript itself follows this principle for XmlHttpRequest, which defines the readyState as type number instead of the literals it could be. TypeScript only uses literals in static data types or for union discrimination.

I will review this right after #8148 is merged (currently it is a bit too large to review, sorry)

@ilevkivskyi -- fyi, I finished rebasing this PR

This should be ready for a second look whenever fyi.